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DETAILED ACTION 

1 . Applicant's amendment dated Feb. 27, 2007, responding to the October 
16, 2006 Office action provided in the rejection of claims 1-19, wherein claims 1, 
7, 10, 14-15, and 17 have been amended, claim 3 is canceled, claims 2, 4-6, 8-9, 
11-13, and 16 are remained as original. 

Claims 1-2, 4-17 remain pending in the application and which have been 
fully considered by the examiner. 

The drawings received are originally filed on October 8, 2003 and 
accepted. 

Applicant's arguments with respect to claims rejection have been fully considered 
but are moot in view of the new grounds of rejection - see Mitchell et al., art made of 
record, as applied hereto. 

Claim Rejections - 35 USC §112 

The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

2. Claims 10-16 are rejected under 35 U.S.C. 112, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the subject 
matter which applicant regards as the invention. 

3. As to claim 10 (currently amended), the claim recites the limitation "a 
machine-readable medium" in line 1 . There is insufficient antecedent basis for 
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this limitation in the claim (see MPEP 608.01 (o)). In the Applicant's remark, 
Applicant states as "any software program must be stored in a machine-readable 
medium cited in P. 1 1 , lines 7-8, however the originally filed specification 
does not reflect as such statements. 

4. As to claims 11-13 (original) and 14 (currently amended), are rejected as 
they depended from rejected base claim 10. 

5. As to claim 15 (currently amended), the claim recites the limitation "a 
machine-readable medium" in line 1. There is insufficient antecedent basis for 
this limitation in the claim (see MPEP 608.01 (o)). In the Applicant's remark, 
Applicant states as "any software program must be stored in a machine-readable 
medium cited in P. 1 1 , lines 7-8, however the originally filed specification 
does not reflect as such statements. 

6. As to claim 16 (original), is rejected as it depended from rejected base 
claim 15. 

Claim Rejections - 35 USC § 101 

35 U.S.C. 101 reads as follows: 



Whoever invents or discovers any new and useful process, machine, manufacture, or 
composition of matter, or any new and useful improvement thereof, may obtain a patent 
therefor, subject to the conditions and requirements of this title. 
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7. Claims 10 and 15 are rejected under 35 U.S. C 101 because the claims 
are directed to non-statutory subject matter. 



8. As to claim 10 (currently amended), the claim recites "a machine- 
readable medium", cited in lines 1-2, 4, 7, 9, 13, and 15; however there is 
insufficient antecedent basis for this limitation in the claim. 

9. As to claim 15 (currently amended), the claim recites "a machine- 
readable medium", cited in line 1; however there is insufficient antecedent basis 
for this limitation in the claim. 



Claim Rejections - 35 USC § 103(a) 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as 
set forth in section 102 of this title, if the differences between the subject matter sought to be 
patented and the prior art are such that the subject matter as a whole would have been obvious at 
the time the invention was made to a person having ordinary skill in the art to which said subject 
matter pertains. Patentability shall not be negatived by the manner in which the invention was 
made. 

10. Claims 1,4, 5, 8-12, 15 and 17 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Shmuel Ur et al., (US 2003/01 10474 A1) (hereinafter 
'Shmuel Ur') in view of Cahill et al., The Java Metrics Reporter- An Extensible 
Tool for OO Software Analysis', 2002 IEEE (hereinafter 'Cahill'), Benlarbi et al., 
Polymorphism Measures for Early Risk Prediction', 1999, ACM) (hereinafter 
'Benlarbi') and further in view of Mitchell et al., 'Toward a definition of run-time 



Application/Control Number: 1 0/681 ,556 Page 5 

Art Unit: 2192 

object-oriented metrics", July 22 nd , 2003, ECOOP (hereinafter 'Mitchell' - art 
made of record) 

11. As to claim 1 (currently amended), Shmuel Ur discloses that a method for 
testing software, comprising: examining an application software program 
including calls to both a static analysis tool and a dynamic analysis tool ([0030], 
lines 1-7); testing said system classes (the dominating blocks) in order according 
to said corresponding proportional weighing attributes ([0005], lines 12-15; 
[0006], lines 22-26 and [0007]). 

But Shmuel Ur does not explicitly disclose calls to system classes from the 
examining; determining a static use count of said system classes from the 
examining; deriving a dynamic use count of each of said system classes during 
operation of said application software program from the examining; assigning a 
proportional weighing attribute to each system class based on its corresponding 
static use count and dynamic use count 

However, in an analogous art, Cahill discloses calls to system classes 
form the examining (Sec. 2.3, the table on page 512, the 1 st entry - System, Root 
Classes); determining a static use count of said system classes from the 
examining (Sec. 3.1 Present Selection and Rationale, 1 st paragraph - fifteen 
metrics organized into the categories Basic (Sec. 3.2), Complexity (3.3), 
Inheritance (Sec. 3.4) and Polymorphism (Sec.3.5). Sec. 3.4, Method Inheritance 
Factor (MIF), lines 1-5 for static use count portion; Sec. 3.5, Polymorphism 
Factor (PF), lines 5-1 1 for dynamic/static use count portion). 
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Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of both Shmuel Ur 
and Cahill in order to calls to system classes from the examining; determining a 
static use count of said system classes from the examining in Shmuel Ur's 
system. 

The motivation is to put highly used software into system classes that can 
be shared between various application classes without mixing them with 
application code. 

It is also well know in the art that polymorphism metrics measure includes 
both static and dynamic information (see Benlarbi, Sec. 3.1 Forms of 
Polymorphism in 00 design, 5 th paragraph - classification of polymorphic 
behaviors includes polymorphic behaviors that are based on run-time binding 
(dynamic) decisions as well as on compile time (static) linking decision). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of Shmuel Ur, Cahill, 
and Benlarbi in order to collect both static and dynamic use count and assigning 
proportional weighing attributes. 

The motivation is that inheritance factor metric (for static use count) is 
useful in providing a direct measure of inheritance in a system, and from this, the 
level or reuse in the system, and polymorphism factor metric (for dynamic count 
use) is useful in indicating complexity, comprehensibility and maintainability. 

Although Cahill discloses both static and dynamic counts (Sec. 3.1 - Sec. 
3.5), but Shmuel UR, Cahill, and Benlarbi do not explicitly disclose deriving a 
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dynamic use count of each of said system classes during operation of said 
application software program from the examining; assigning a proportional 
weighing attribute to each system class based on its corresponding static use 
count and dynamic use count. 

However, in an analogous art of toward a definition of run-time object- 
oriented metrics, Mitchell discloses deriving a dynamic use count of each of said 
system classes during operation of said application software program from the 
examining; assigning a proportional weighing attribute to each system class 
based on its corresponding static use count and dynamic use count (Sec. 1, 3 rd 
Para. - static metrics alone may be insufficient in evaluating the dynamic 
behavior of an application at run time, as its behavior will be influenced by the 
operational environment as well as the complexity of the source code; Sec. 2, 2 nd 
Para. - to quantify the external quality of a software product using a set of 
dynamic metrics calculated at run-time that evaluate the product's complexity. 
These metrics by themselves can provide us with useful information, and can 
also help to calibrate the information obtained from a static analysis, 5 th Para. - 
The quality of a software product will be influenced by its operational 
environment as well as the source code complexity, therefore it was believed that 
measures that assess run-time quality may aid in the analysis of software quality. 
Static coupling and cohesion metrics deal with the architectural aspects of a 
software system, whereas run-time measures necessarily deal also with the 
behavioral aspects of the system; Sec. Ill Work Done To Date, 1 st Para., 3 rd 
Para., 4 th Para., 5 th Para. - it is known that a one-to-one relationship does not 
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exist between static and dynamic metrics but our study indicated that there might 
be some co-relation; Sec. A. Relationship with Software Testing, 4 th Para. - to 
determine if a quantifiable correlation exists between the information obtained 
from a static and dynamic analysis of a program; clearly, a static analysis is 
relatively independent of program behavior, whereas any run-time analysis will 
be fundamentally influenced by the testing strategy and test inputs; Fig. 1 - 
Degree of Static and Dynamic Coupling within a group of classes for the non-API 
classes of the programs from SPEC JVM98 benchmark suite; Sec. A - Coupling 
Metrics; Sec. B - Cohesion Metrics - Figs 2-3 give a pictorial representation of 
the relationship between the static and dynamic cohesion data ...). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of Mitchell into 
Shmuel Ur-Cahill-Benlarbi system to further derive a dynamic use count of each 
of said system classes during operation of said application software program 
from the examining; assign a proportional weighing attribute to each system 
class based on its corresponding static use count and dynamic use count in 
Shmuel Ur-Cahill-Benlarbi system. 

The motivation is that it would further enhance the Shmuel Ur-Cahill- 
Benlarbi's system by taking, advancing and/or incorporating Mitchell's system 
which offers significant advantages to quantify the external quality of a software 
product using a set of dynamic metrics calculated at run-time that evaluate the 
product's complexity; these metrics by themselves can provide us with useful 
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information, and can also help to calibrate the information obtained from a static 
analysis as once suggested by Mitchell (Sec. II. - Related Work, 2 nd Para.). 

12. As to claim 10 (currently amended), Shmuel Ur discloses a machine- 
readable medium on which is encoded machine readable code for testing object- 
oriented system software having system classes, the machine readable code 
comprising: machine-readable code for running a static analysis tool for 
examining an application software program; machine-readable code for running a 
dynamic analysis tool for examining the application software program ([0030], 
lines 1-7); machine-readable code for testing said system classes (the 
dominating blocks) in order, based on the assigned weight, from a first entry 
having a greatest weight ([0005], lines 12-15; [0006], lines 22-26 and [0007]). 

But, Shmuel Ur does not explicitly disclose calls to system classes. 
However, in an analogous art, Cahill discloses calls to system classes (Sec. 2.3, 
the table on page 512, the 1 st entry - System, Root Classes). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of both Shmuel Ur 
and Cahill in order to call to system classes. 

The motivation is to put highly used software into system classes that can 
be shared between various application classes without mixing them with 
application code. 

Further, Shmuel Ur does not disclose that machine-readable code for 
determining a static use count of the system classes in the application software 



Application/Control Number: 10/681,556 Page 
Art Unit: 2192 

program from the result; machine-readable code for assigning to each system 
class a weight based on the static use count and the dynamic use count. 

However, in an analogous art, Cahill discloses that machine-readable 
code for determining a static use count of the system classes in the application 
software program from the result (Sec. 3.1 Present Selection and Rationale, 1 st 
paragraph - fifteen metrics organized into the categories Basic (Sec. 3.2), 
Complexity (3.3), Inheritance (Sec. 3.4) and Polymorphism (Sec.3.5). Sec. 3.4, 
Method Inheritance Factor (MIF), lines 1-5 for static use count portion; Sec. 3.5, 
Polymorphism Factor (PF), lines 5-1 1 for dynamic/static use count portion). 

It is also well know in the art that polymorphism metrics measure includes 
both static and dynamic information (see Benlarbi, Sec. 3.1 Forms of 
Polymorphism in 00 design, 5 th paragraph - classification of polymorphic 
behaviors includes polymorphic behaviors that are based on run-time binding 
(dynamic) decisions as well as on compile time (static) linking decision). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of Shmuel Ur, Cahill 
and Benlarbi in order to determine a static use count of the system classes in the 
application software program from the result in Shmuel Ur's system. 

The motivation is that inheritance factor metric (for static use count) is 
useful in providing a direct measure of inheritance in a system, and from this, the 
level or reuse in the system, and polymorphism factor metric (for dynamic count 
use) is useful in indicating complexity, comprehensibility and maintainability. 
Shmuel Ur discloses that testing said 'system classes' (the dominating blocks) in 
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order according to said corresponding proportional weighing attributes ([0005], 
lines 12-15; [0006], lines 22-26 and [0007]). 

Although Cahill discloses both static and dynamic counts (Sec. 3.1 - Sec. 
3.5), but Shmuel UR, Cahill, and Benlarbi do not explicitly disclose machine- 
readable code for producing a dynamic use count based on the application 
software program's dynamic use of the system functions while running the 
application software program and assigning to each system class a weight based 
on the static use count and the dynamic use count. 

However, in an analogous art of toward a definition of run-time object- 
oriented metrics, Mitchell discloses machine-readable code for producing a 
dynamic use count based on the application software program's dynamic use of 
the system functions while running the application software program and 
assigning to each system class a weight based the static use count and the 
dynamic use count (Sec. 1 , 3 rd Para. - static metrics alone may be insufficient in 
evaluating the dynamic behavior of an application at run time, as its behavior will 
be influenced by the operational environment as well as the complexity of the 
source code; Sec. 2, 2 nd Para. - to quantify the external quality of a software 
product using a set of dynamic metrics calculated at run-time that evaluate the 
product's complexity. These metrics by themselves can provide us with useful 
information, and can also help to calibrate the information obtained from a static 
analysis, 5 th Para. - the quality of a software product will be influenced by its 
operational environment as well as the source code complexity, therefore it was 
believed that measures that assess run-time quality may aid in the analysis of 
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software quality. Static coupling and cohesion metrics deal with the architectural 
aspects of a software system, whereas run-time measures necessarily deal also 
with the behavioral aspects of the system; Sec. Ill Work Done To Date, 1 st Para., 
3 rd Para., 4 th Para., 5 th Para. - it is known that a one-to-one relationship does not 
exist between static and dynamic metrics but our study indicated that there might 
be some co-relation; Sec. A. Relationship with Software Testing, 4 th Para. - to 
determine if a quantifiable correlation exists between the information obtained 
from a static and dynamic analysis of a program; clearly, a static analysis is 
relatively independent of program behavior, whereas any run-time analysis will 
be fundamentally influenced by the testing strategy and test inputs; Fig. 1 - 
Degree of Static and Dynamic Coupling within a group of classes for the non-API 
classes of the programs from SPEC JVM98 benchmark suite; Sec. A - Coupling 
Metrics; Sec. B - Cohesion Metrics - Figs 2-3 give a pictorial representation of 
the relationship between the static and dynamic cohesion data ...). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of Mitchell into 
Shmuel Ur-Cahill-Benlarbi system to further provide machine-readable code for 
assigning to each system class a weight based the static use count and the 
dynamic use count in Shmuel Ur-Cahill-Benlarbi system. 

The motivation is that it would further enhance the Shmuel Ur-Cahill- 
Benlarbi's system by taking, advancing and/or incorporating Mitchell's system 
which offers significant advantages to quantify the external quality of a software 
product using a set of dynamic metrics calculated at run-time that evaluate the 
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product's complexity; these metrics by themselves can provide us with useful 
information, and can also help to calibrate the information obtained from a static 
analysis as once suggested by Mitchell (Sec. II. - Related Work, 2 nd Para.). 

13. As to claim 15 (currently amended), Shmuel Ur discloses a machine- 
readable medium on which is encoded a software tester program code, the 
software tester program code comprising: means for examining an application 
software program including calls to both a static analysis tool and a dynamic 
analysis tool ([0030], lines 1-7); means for testing said system classes (the 
dominating blocks) in order according to said corresponding proportional 
weighing attributes ([0005], lines 12-15; [0006], lines 22-26 and [0007]). 

But, Shmuel Ur does not explicitly disclose to call to system classes. 

However, in the analogous art, Cahill discloses to call to system classes 
(Sec. 2.3, the table on page 512, the 1 st entry - System, Root Classes). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of both Shmuel Ur 
and Cahill in order to call to system classes. 

The motivation is to put highly used software into system classes that can 
be shared between various application classes without mixing them with 
application code. 

Further, Shmuel Ur does not disclose means for determining a static use 
count of said system classes from the examining; means for deriving a dynamic 
use count of each of said system classes during operation of said application 
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software program from the examining; means for assigning a proportional 
weighing attribute to each system class based on its corresponding static use 
count and dynamic use count. 

However, in an analogous art, Cahill discloses that means for determining 
a static use count of said system classes from the examining (Sec. 3.1 Present 
Selection and Rationale, 1 st paragraph - fifteen metrics organized into the 
categories Basic (Sec. 3.2), Complexity (3.3), Inheritance (Sec. 3.4) and 
Polymorphism (Sec.3.5). Sec. 3.4, Method Inheritance Factor (MIF), lines 1-5 for 
static use count portion; Sec. 3.5, Polymorphism Factor (PF), lines 5-1 1 for 
dynamic/static use count portion). 

It is also well know in the art that polymorphism metrics measure includes 
both static and dynamic information (see Benlarbi, Sec. 3.1 Forms of 
Polymorphism in 00 design, 5 th paragraph - classification of polymorphic 
behaviors includes polymorphic behaviors that are based on run-time binding 
(dynamic) decisions as well as on compile time (static) linking decision). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of Shmuel Ur, Cahill 
and Benlarbi in order to collect both static and dynamic use count and assigning 
proportional weighing attributes. 

The motivation is that inheritance factor metric (for static use count) is 
useful in providing a direct measure of inheritance in a system, and from this, the 
level or reuse in the system, and polymorphism factor metric (for dynamic count 
use) is useful in indicating complexity, comprehensibility and maintainability. 
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Although Cahill discloses both static and dynamic counts (Sec. 3.1 - Sec. 
3.5), but Shmuel UR, Cahill, and Benlarbi do not explicitly disclose means for 
deriving a dynamic use count of each of said system classes during operation of 
said application software program from the examining; means for assigning a 
proportional weighing attribute to each system class based on its corresponding 
static use count and dynamic use count. 

However, in an analogous art of toward a definition of run-time object- 
oriented metrics, Mitchell discloses means for means for deriving a dynamic use 
count of each of said system classes during operation of said application 
software program from the examining; assigning a proportional weighing attribute 
to each system class based on its corresponding static use count and dynamic 
use count (Sec. 1, 3 rd Para. - static metrics alone may be insufficient in 
evaluating the dynamic behavior of an application at run time, as its behavior will 
be influenced by the operational environment as well as the complexity of the 
source code; Sec. 2, 2 nd Para. - to quantify the external quality of a software 
product using a set of dynamic metrics calculated at run-time that evaluate the 
product's complexity. These metrics by themselves can provide us with useful 
information, and can also help to calibrate the information obtained from a static 
analysis, 5 th Para. - the quality of a software product will be influenced by its 
operational environment as well as the source code complexity, therefore it was 
believed that measures that assess run-time quality may aid in the analysis of 
software quality. Static coupling and cohesion metrics deal with the architectural 
aspects of a software system, whereas run-time measures necessarily deal also 
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with the behavioral aspects of the system; Sec. Ill Work Done To Date, 1 st Para., 
3 rd Para., 4 th Para., 5 th Para. - it is known that a one-to-one relationship does not 
exist between static and dynamic metrics but our study indicated that there might 
be some co-relation; Sec. A. Relationship with Software Testing, 4 th Para. - to 
determine if a quantifiable correlation exists between the information obtained 
from a static and dynamic analysis of a program; clearly, a static analysis is 
relatively independent of program behavior, whereas any run-time analysis will 
be fundamentally influenced by the testing strategy and test inputs; Fig. 1 - 
Degree of Static and Dynamic Coupling within a group of classes for the non-API 
classes of the programs from SPEC JVM98 benchmark suite; Sec. A - Coupling 
Metrics; Sec. B - Cohesion Metrics - Figs 2-3 give a pictorial representation of 
the relationship between the static and dynamic cohesion data ...). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of Mitchell into 
Shmuel Ur-Cahill-Benlarbi system to further provide means for deriving a 
dynamic use count of each of said system classes during operation of said 
application software program from the examining; means for assigning a 
proportional weighing attribute to each system class based on its corresponding 
static use count and dynamic use count in Shmuel Ur-Cahill-Benlarbi system. 

The motivation is that it would further enhance the Shmuel Ur-Cahill- 
Benlarbi^ system by taking, advancing and/or incorporating Mitchell's system 
which offers significant advantages to quantify the external quality of a software 
product using a set of dynamic metrics calculated at run-time that evaluate the 
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product's complexity; these metrics by themselves can provide us with useful 
information, and can also help to calibrate the information obtained from a static 
analysis as once suggested by Mitchell (Sec. II. - Related Work, 2 nd Para.). 

14. As to claim 17 (currently amended), Shmuel Ur discloses a business 
model for testing software, comprising: setting a resource limit on the available 
time or money that is devoted to testing a particular application software 
program; examining an application software program including calls to both a 
static analysis tool and a dynamic analysis tool ([0030], lines 1-7); stopping 
testing when said resource limit is reached ([0097], lines 1-6; [0049]); testing said 
'system classes' (the dominating blocks) in order according to said corresponding 
proportional weighing attributes ([0005], lines 12-15; [0006], lines 22-26 and 
[0007]); a business model factors for testing software ([0004], lines 12-14). 

But Shmuel Ur does not explicitly disclose to call to system classes. 
However, in the analogous art, Cahill discloses to call to system classes (Sec. 
2.3, the table on page 512, the 1 st entry - System, Root Classes). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of both Shmuel Ur 
and Cahill in order to call to system classes. 

The motivation is to put highly used software into system classes that can 
be shared between various application classes without mixing them with 
application code. 
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Shmuel Ur does not disclose that determining a static use count of said 
system classes from the examining; deriving a dynamic use count of each of said 
system classes during operation of said application software program from the 
examining; assigning a proportional weighing attribute to each system class 
based on its corresponding static use count and dynamic use count. 

However, in an analogous art, Cahill discloses that determining a static 
use count of said system classes from the examining; deriving a dynamic use 
count of each of said system classes during operation of said application 
software program from the examining (Sec. 3.1 Present Selection and Rationale, 
1 st paragraph - fifteen metrics organized into the categories Basic (Sec. 3.2), 
Complexity (3.3), Inheritance (Sec. 3.4) and Polymorphism (Sec.3.5). Sec. 3.4, 
Method Inheritance Factor (MIF), lines 1-5 for static use count portion; Sec. 3.5, 
Polymorphism Factor (PF), lines 5-1 1 for dynamic/static use count portion). 

It is also well know in the art that polymorphism metrics measure includes 
both static and dynamic information (see Benlarbi, Sec. 3.1 Forms of 
Polymorphism in 00 design, 5 th paragraph - classification of polymorphic 
behaviors includes polymorphic behaviors that are based on run-time binding 
(dynamic) decisions as well as on compile time (static) linking decision). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of Shmuel Ur, Cahill 
and Benlarbi in order to collect both static and dynamic use count and assigning 
proportional weighing attributes. 
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The motivation is that inheritance factor metric (for static use count) is 
useful in providing a direct measure of inheritance in a system, and from this, the 
level or reuse in the system, and polymorphism factor metric (for dynamic count 
use) is useful in indicating complexity, comprehensibility and maintainability. 

Although Cahill discloses both static and dynamic counts (Sec. 3.1 - Sec. 
3.5), but Shmuel UR, Cahill, and Benlarbi do not explicitly disclose assigning a 
proportional weighing attribute to each system class based on its corresponding 
static use count and dynamic use count. 

However, in an analogous art of toward a definition of run-time object- 
oriented metrics, Mitchell discloses assigning a proportional weighing attribute to 
each system class based on its corresponding static use count and dynamic use 
count (Sec. 1 , 3 rd Para. - static metrics alone may be insufficient in evaluating 
the dynamic behavior of an application at run time, as its behavior will be 
influenced by the operational environment as well as the complexity of the source 
code; Sec. 2, 2 nd Para. - to quantify the external quality of a software product 
using a set of dynamic metrics calculated at run-time that evaluate the product's 
complexity. These metrics by themselves can provide us with useful information, 
and can also help to calibrate the information obtained from a static analysis, 5 th 
Para. - the quality of a software product will be influenced by its operational 
environment as well as the source code complexity, therefore it was believed that 
measures that assess run-time quality may aid in the analysis of software quality. 
Static coupling and cohesion metrics deal with the architectural aspects of a 
software system, whereas run-time measures necessarily deal also with the 
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behavioral aspects of the system; Sec. Ill Work Done To Date, 1 st Para., 3 rd 
Para., 4 th Para., 5 th Para. - it is known that a one-to-one relationship does not 
exist between static and dynamic metrics but our study indicated that there might 
be some co-relation; Sec. A. Relationship with Software Testing, 4 th Para, - to 
determine if a quantifiable correlation exists between the information obtained 
from a static and dynamic analysis of a program; clearly, a static analysis is 
relatively independent of program behavior, whereas any run-time analysis will 
be fundamentally influenced by the testing strategy and test inputs; Fig. 1 - 
Degree of Static and Dynamic Coupling within a group of classes for the non-API 
classes of the programs from SPEC JVM98 benchmark suite; Sec. A - Coupling 
Metrics; Sec. B - Cohesion Metrics - Figs 2-3 give a pictorial representation of 
the relationship between the static and dynamic cohesion data .,.). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of Mitchell into 
Shmuel Ur-Cahill-Benlarbi system to further assign a proportional weighing 
attribute to each system class based on its corresponding static use count and 
dynamic use count in Shmuel Ur-Cahill-Benlarbi system. 

The motivation is that it would further enhance the Shmuel Ur-Cahill- 
Benlarbi's system by taking, advancing and/or incorporating Mitchell's system 
which offers significant advantages to quantify the external quality of a software 
product using a set of dynamic metrics calculated at run-time that evaluate the 
product's complexity; these metrics by themselves can provide us with useful 
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information, and can also help to calibrate the information obtained from a static 
analysis as once suggested by Mitchell (Sec. II. - Related Work, 2 nd Para.). 

15. As to claim 4 (original) (incorporating the rejection in claim 1) and Claim 

11 (incorporating the rejection in claim 10), Shmuel Ur does not specifically 
disclose that producing a static use count further comprises assigning a static 
observation percentage to each system class by dividing said static use count by 
a sum of all static use counts. 

However, in an analogous art, Cahill discloses that producing a static use 
count further comprises assigning a static observation percentage to each 
system class by dividing said static use count by a sum of all static use counts 
(Sec. 3.4, Method Inheritance Factor (MIF), lines 2-5). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of both Shmuel Ur 
and Cahill in order to produce static observation percentage for each system 
class. 

The motivation is that static observation percentage is useful in providing 
a direct measure of inheritance in a system, and from this, the level of reuse in 
the system. 

16. As to claim 5 (original) (incorporating the rejection in claim 1) and claim 

12 (incorporating the rejection in claim 10), Shmuel Ur does not specifically 
disclose that producing a dynamic use count further comprises assigning a 
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dynamic observation percentage to each system class by dividing said dynamic 
use count by a sum of all dynamic use counts. 

However, in an analogous art, Cahill discloses that producing a dynamic 
use count further comprises assigning a dynamic observation percentage to each 
system class by dividing said dynamic use count by a sum of all dynamic use 
counts (Sec. 3.5, Polymorphism Factor (PF), Lines 2-7). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of both Shmuel Ur 
and Cahill in order to produce dynamic observation percentage for each system 
class. The motivation is that dynamic observation percentage is useful in 
indicating complexity, comprehensibility and maintainability. 

17. As to claim 8 (original) (incorporating the rejection in claim 1), Shmuel Ur 
discloses that the testing system classes further comprises ending a test when a 
testing resource is exhausted and prior to testing a last entry have a least weight 
([0004], lines 12-14). 

18. As to claim 9 (original) (incorporating the rejection in claim 8), Shmuel Ur 
discloses that the testing system classes further comprises ending a test when at 
least a limit of available time or funding is exhausted and prior to testing a last 
entry having a least weight ([0004], lines 12-14). 
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19. Claims 6 and 1 3 are rejected under 35 U.S.C. 1 03(a) as being 
unpatentable over Shmuel Ur, in view of Cahill & Benlarbi and further in view of 
T. Ball (The Concept of Dynamic Analysis', Bell Laboratories Lucent 
Technologies, Oct, 1999') (hereinafter 'Ball') 

20. As to claim 6 (original) (incorporating the rejection in claim 1 ) and claim 
13 (incorporating the rejection in claim 10), Shmuel Ur, Benlarbi, and Cahill does 
not disclose that producing a static use count further comprises assigning a static 
observation percentage to each system class by diving the static use count by a 
sum of all static use counts; and producing a dynamic use count further 
comprises assigning a dynamic observation percentage to each system class by 
dividing the dynamic use count by a sum of all dynamic use counts. 

However, in an analogous art, Ball discloses that producing a static use 
count further comprises assigning a static observation percentage to each 
system class by diving the static use count by a sum of all static use counts; and 
producing a dynamic use count further comprises assigning a dynamic 
observation percentage to each system class by dividing the dynamic use count 
by a sum of all dynamic use counts (Sec. 1 , dynamic and static analyses are 
complementary techniques in a number of dimensions: a) completeness, b) 
scope, and c) precision). 

Therefore, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to combine the teachings of Shmuel Ur, Cahill, 
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Benlarbi and Ball in order to produce static plus dynamic observation 
percentages for each system class. 

The motivation is that both static and dynamic observation percentages for 
each system class are complementary metrics factors to product more complete, 
precise, scope combined software metrics report. 

21 . Claims 2 and 1 6 are rejected under 35 U.S.C. 1 03(a) as being 
unpatentable over Shmuel Ur, Cahill and Benlarbi, in view of Kuzmin et al., (pat. 
no. US 7,039,902 B2) (hereinafter 'Kuzmin'), 

22. As to claim 2 (original) (incorporating the rejection in claim 1) and claim 
16 (incorporating the rejection in claim 15), Shmuel Ur, Cahill and Benlarbi do not 
disclose that wherein the step of testing is such that only the most heavily 
weighted portion of all such system classes are test at all. 

However, in an analogous art, Kuzmin discloses that wherein the step of 
testing is such that only the most heavily weighted portion of all such system 
classes are tested at all (Col. 5, lines 48, 53). 

It would have been obvious to one of ordinary skill in the art at the time of 
invention was made to combine the teachings of Shmuel Ur, Cahill, Benlarbi and 
Kuzmin in order to focus on testing in most heavily weighted portion of all such 
system classes. 
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The motivation is that prioritization of untested portions of code is 
advantageous because it finds the untested portions with the most potential 
impact in the body of application code. 

23. As to claim 3 (cancelled) 

Allowable Subject Matter 

24. Claims 7 and 14 are objected to as being dependent upon a rejected base 
claim, but would be allowable if rewritten to overcome the rejections under 35 
U.S.C. 101 and 35 U.S.C. 112, 2 nd paragraph set forth in this office action and to 
include all the limitations of the base claim and any intervening claims. 

The following is an examiner's statement of reasons for allowance: 

Regarding claims 7 and 14, prior art of record fails to reasonably show or 
suggest the specific weighting scheme as claimed. Specifically, the assigning a 
first weight defined by a first constant plus a sum of the static use count plus the 
dynamic use count, a second weight equal to the first constant, further assigning 
a third weight as a second constant that is less than the first constant (which is 
added a sum of the static and dynamic observation percentage), and assigning 
to all remaining classes a fourth weight less than the second constant. 

Any comments considered necessary by applicant must be submitted no 
later than the payment of the issue fee and, to avoid processing delays, should 
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preferably accompany the issue fee. Such submissions should be clearly labeled 
"Comments on Statement of Reasons for Allowance." 



Conclusion 

25. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure. 

• Mitchell et al., "Run-time Coupling Metrics for the Analysis of Java 
Programs - preliminary results form the SPEC and Grande suites", 
Technical Report NUIM-CS-TR2003-07, Dept. of Computer Science, 
NUI Maynooth, Ireland, April 2003 

• Mitchell et al., "Run-time Cohesion Metrics for the Analysis of Java 
Program - preliminary results form the SPEC and Grande suites" 
Technical Report NUIM-CS-TR2003-08, Dept. of Computer Science, 
NUI Maynooth, Ireland, April 2003 

• Michael et al., "Metrics for Measuring the Effectiveness of Software- 
Testing Tools", 2002, IEEE 

26. Any inquiry concerning this communication or earlier communications from 
the examiner should be directed to Ben C. Wang whose telephone number is 
571-270-1240. The examiner can normally be reached on Monday - Friday, 8:00 
a.m. - 5:00 p.m., EST. 
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If attempts to reach the examiner by telephone are unsuccessful, the 
examiner's supervisor, Tuan Q. Dam can be reached on 571-272-3695. The fax 
phone number for the organization where this application or proceeding is 
assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from 
the Patent Application Information Retrieval (PAIR) system. Status information 
for published applications may be obtained from either Private PAIR or Public 
PAIR. Status information for unpublished applications is available through 
Private PAIR only. For more information about the PAIR system, see http://pair- 
direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll- 
free). If you would like assistance from a USPTO Customer Service 
Representative or access to the automated information system, call 800-786- 
9199 (IN USA OR CANADA) or 571-272-1000. 
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